Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000073_owner-urn-ietf _Tue Oct 22 17:32:01 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA16270 for urn-ietf-out; Tue, 22 Oct 1996 17:32:01 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA16265 for <[e-mail]>; Tue, 22 Oct 1996 17:31:59 -0400
Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA10822  (mail destined for [e-mail]); Tue, 22 Oct 96 17:31:57 -0400
Received: from nic.cafax.se ([e-mail] [193.12.122.42])
        by nic.cafax.se (8.8.2/8.8.2) with SMTP
        id XAA25263;
        Tue, 22 Oct 1996 23:31:48 +0200 (MET DST)
Date: Tue, 22 Oct 1996 23:31:48 +0200 (MET DST)
From: Patrik Faltstrom <[e-mail]>
X-Sender: [e-mail]
To: Larry Masinter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [URN] Pre release of URN Syntax document....
In-Reply-To: <96Oct22.135155pdt."2759"@golden.parc.xerox.com>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: Patrik Faltstrom <[e-mail]>
Errors-To: [e-mail]

On Tue, 22 Oct 1996, Larry Masinter wrote:

> >   o Simple comparison: A comparison algorithm for URNs is simple,
> >     local, and deterministic. That is, there is a single algorithm for
> >     comparing two URNs that does not require contacting any external
> >     server, is well specified and simple.
>
> This was discussed at length. It's true that it would be useful for
> those who know about ISBNs to allow both isbn:0-201-10174-2 and
> isbn:0210101742, but having a large variety of syntactic equivalences
> has a large cost.

What I am trying to say is that the general URN comparison algorithm
must define a case of equivalence which is useful for some applications,
but not for other. It can only deal with lexical equivalence,
and what we are discussing are things like if the decomposition
rules in UNICODE should be part of these lexical equivalence
rules.

On a different level, the namespace itself can define a kind
of equivalence which makes it possible for example to use
the urn "urn:isbn:0-201-10174-2" or "urn:isbn:0210101742"
and get the same object. They are syntactical equivalent,
but not lexical.

> For example, the NAPTR resolution scheme depends on regular expression
> patterns which will not work well if all of the different syntactic
> variations of URNs might be allowed.

The NAPTR proposal does only say that you can use regular expressions
to find the resolution service. When you have found that service,
you always pass the full URN to that service (if nothing special
is specified as a protocol specific functionality). So far in the
NAPTR proposal, _no_ regular expression is operating on the
opaque string, even though that is possible, and interesting,
in some namespaces.

You have to remember that the regular expression is constructed
and stored by the owner of the URN which the expression is
operating on, so that person knows what target the expression
is operating on. Just like the fact that one namespace might
have its own ways of defining the word equivalence when accessing
the final resolution service.

> So I disagree with the assertion:
>
> # For an ISBN, the followings should be equivalent:
> #   isbn:0-201-10174-2
> #   isbn:0201101742
>
> If you're going to 'grandfather' ISBN numbers, you should do so in a
> single unambiguous way.

You have to differ between what result you get when you "just"
compare the lexical equivalence between the two urns and what
you get when you try to resolve the two urns in the final
resolver which knows about isbns. I.e. one thing is the
equivalence when looking at them as urns, and then they
are different, but later, when having knowledge about the
isbn namespace, they should be equivalent.

One thing is defined in the urn paper, and one in the paper
which describes the isbn namespace.

I don't think the urn paper and the namespace papers have to
have the same definition of "equivalent".

   Patrik